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REMARKS 

I. Introduction. 

In response to the Office Action dated June 4, 2004, no claims have been cancelled, 
amended or added. Claims 1-4, 6, 8- 10, 12-15, 17, 19-21, 23-26, 28, 30-32, 34-39 remain in the 
application. Reexamination and re-consideration of the application is requested. 

II. Prior Art Rejections 

A. The Office Action Rejections 

In paragraphs (3)-(4) of the Office Action, claims 1-3, 6, 8-10, 12-14, 17, 19-21, 23-25, 28, 
30-32, 34, and 36-38 were rejected under 35 US.C §103(a) as being unpatentable over Hunt, US. 
Patent No. 6,154/47 (Hunt) in view of Fischer, US. Patent No. 6,105,072 (Fischer) and further in 
view of Morel et al., US. Patent No. 5,721,919 (Morel). In paragraph (7) of the Office Action, 
claims 4, 15, 26, 35, and 39 were rejected under 35 US.C 5103(a) as being unpatentable over Hunt, 
Fischer, and Morel as applied to claims 1, 23, and 34, and further in view of Moore, US. Patent No. 
5,343,527 (Moore). 

Applicants' attorney respectfully traverses these rejections. 
B. The Applicants' Indep endent Hai'ms 

Independent claims 1, 12 and 23 ate generally directed to checking a version of an abstract 
data type stored in a database. Independent claim 1 is representative, and comprises: 

(a) constructing an identifier for the abstract data type, wherein the identifier comprises a 
concatenation of various attributes for the abstract data type that is substantially unique to the 
abstract data type; 

(b) hashing the constructed identifier to generate a signature hash value for the abstract data 

type; 

(c) storing the signature hash value in the database and a class definition for the abstract data 
type; and 

(d) comparing the signature hash value from the database with the signature hash value from 
the class definition after the class definition is instantiated in order to verify that the class definition 
is not outdated. 
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Independent claims 6, 17 and 28 arc generally directed to generating a signature hash value 
for checking a version of an abstract data type stored in databases. Independent claim 6 is 
representative, and comprises: 

(a) constructing an identifier for the abstract data type, wherein the identifier comprises a 
concatenation of various attributes for the abstract data type that is substantially unique to the 
abstract data type; 

(b) hashing the constructed identifier to generate a signature hash value for the abstract data 
type; and 

(c) storing the signature hash value in the database and a class for the abstract data type. 
Independent claims 8, 19 and 30 are generally directed to verifying a signature hash value for 

checking a version of an abstract data type stored in a database. Independent claim 8 is 
representative, and comprises: 

(a) accessing a first signature hash value from the database and a second signature hash value 
from a class definition for the abstract data type, wherein the first and second signature hash values 
have been constructed from an identifier for the ahstract data type, the identifier comprises a 
concatenation of various attributes for the abstract data type that is substantially unique to the 
abstract data type, and the identifier has been hashed to generate the first and second signature hash 
values; and 

comparing the first signature hash value with the second signature hash value after the 
class definition is instantiated in order to verify that the class definition is not outdated. 

Independent claim 34 is directed to at least one data structure stored in a memory for use in 
checking a version of an abstract data type stored in a database, the data structure comprising a 
signature hash value for the abstract data type generated from an identifier constructed for the 
abstract data type, wherein the identifier comprises a concatenation of various attributes for the 
abstract data type that is substantially unique to the abstract data type and the identifier is hashed to 
generate the signature hash value for the abstract data type. 

C The Hunt Reference 

Hunt describes a method using a plurality of hash tables to provide an object repository for 
object oriented application development and use. The method includes storing an object identifier 
and a representation of the object in a first hash table and storing data about the object and the 
object identifier in a plurality of paired hash tables with the bash tables organized in mirrored table 
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pain. Hie data about the object include an object's class name, object methods, return types, and the 
data values returned by object methods, The non-inverse hash tables of the rnirrored table pairs 
support fuzzy searches for objects while the inverse hash tables of the mirrored tabk pairs support 
searches for objects by object identifier. A system that implements the inventive method includes a 
first hash table for storage of data representing the object with an object identifier used as a key for 
storage of the representing data and a plurality of rnirrored table pairs for the storage of data about 
objecu. In the non-inverse table of the mirrored table pairs, the data about the objects are used as 
keys to store an object identifier. In the inverse tables of the mirrored table pairs, the object 
identifier is used as the key for storage of the data about the data objects. The rnirrored table pairs 
and hash table provide an efficient and economical object repository. Such an object repository may 
be provided with a computer application at a nominal expense. Thus, object oriented applications 
may be developed without regard for whether the end user system includes an object repository. 

D- Hie Fischer Referent 

Fischer describes a method of operating computers in accordance with an enhanced object- 
oriented programming methodology that creates a framework for efficiently performing automated 
business transactions. The object-oriented prograinming methodology is used in conjunction with a 
travelling program, i.e., a digital data structure which includes a sequence of instructions and 
associated data whict has the capability of detennining at feast one next destination or recipient for 
receiving the travelling program and for transmitting itself, together with all relevant data determined 
by the program to the next recipient or destination Using the methods described herein, the data is 
more closely bound to the program in such a way that objects may be most efficiently transferred 
from one computer user to another without the objects being previously known to the recipient 
computer user. The present invention utilizes object "cells" which are data structures stored, for 
example, on a disk that reflects a collection of (related) objects instances whose execution has been 
suspended, and which can be resumed later on the same or a different platform. The collection of 
object instances can be gathered together into cells (or "electronic forms") suitable for storage or 
transmission to another computer user in such a way that instances are unambiguously bound to 
their respective class definition. The present invention also creates improved tools for creating and 
using cells so that electronic forms can be defined using object-oriented techniques while allowing 
such forms to be easily transferred among a diverse population of computer users-without 
demanding that all users maintain compatible libraries of all object-class defimtion programs and 
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without demanding that all users maintain identical synchronized versions of that class. The 
invention provides a digital signature methodology to insure security and integrity, 50 that electronic 
forms (i.e., cells) composed of a collection of objects can be received and executed by a user without 
putting the user at risk that some of the object classes embedded in the cell might be subversive 
"trojan horse" programs that might steal, destroy or otherwise compromise the security or integrity 
of the user's system or data. 

E. The Morel Reference 

Morel describes a method and system for tracking, and resolving Unlcc to, objects that derive 
from a common object creation. In a system, the system creates a source object. The system then 
generates a lineage identifier to identify the creation of the source object. Then the system associates 
the lineage identifier with the source object. At a later time, the system copies the created object to a 
copy object. When the source object is copied to a copy object, the system associates the lineage 
identifier associated with the source object with the copy object. In this way, the lineage identifier 
associated with the copy object indicates that the copy object derives from the creation of the source 
object. The system links a client object to a source object by storing a link containing the source 
object's lineage identifier in the client object. A link also contains information for distinguishing the 
source object from other objects having the same lineage identifier. When resolving the link to the 
source object, the system selects the lineage identifier and the distinguishing information contained 
in the link The system then searches for an object with the selected lineage identifier and 
distinguishing information. When an object with the selected lineage identifier and distinguishing 
information is found, the system resolves the link to the found object. When an object with the 
selected lineage identifier and distinguishing information is not found, the system searches for an 
object with the selected lineage identifier without regard to the selected distinguishing information. 
When an object with the selected lineage identifier is found, the system resolves the link to this 
found object. 

F. The Moore Reference 

Moore describes a system and method for providing a reuser of a software reuse library with 
an indication of whether or not a software component from the reuse library is authentic and 
whether or not the software component has been modified Hie system and method disclosed 
provides a reuser with assurance that the software component retrieved was placed in the reuse 
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library by the original publisher and has not modified by a thud party. The system and method 
disclosed uses a hybrid cryptographic technique that combines a conventional or private key 
algorithm with a public key algorithm. 

G ' Hie Applicants' Claims Am Pat e ntable Over Th e Reference 

Applicants' invention, as recited in the claims, is patentable over the references, because the 

claims recite limitations not found in the references. 

On the other hand, die Office Action asserts that Hunt teaches the construction of an 

identifier for the abstract data type where the identifier is substantially unique to the data type and 

the identifier comprises a concatenation of various attributes for the dam type, at column 6, lines 43- 

45 and column 7, lines 42-49. 

However, at the cited locations, Hunt merely discloses the following: 

Hunt, column 6. lines 43-45 (actually W« 2?-tf ) 
A preferred structure for object repository 18 that maybe accessed by an 
instance of the gateway depicted in FIG. 3 is shown in FIG. 4. Object repository 18 
includes a single hash table 62 and hash table pairs 64, 68, 72, and 74 which are 
organized in mirrored table pairs. Each mirrored table pair is comprised of a non- 
inverse hash table and an inverse hash table. The inverse tables are so referenced 
b^ause they reverse the key/value organization of the non-inverse hash tables 
Mirrored table pair 64 stores class names for objects. Mirrored table pair 68 stores 
data regarding the methods used by the objects stored in repository 18 and mirrored 
table parr 72 stores data regarding return types for the methods of the objects stored 
in repository 18. Mirrored table pair 74 is used to store data values returned by the 
methoos for objects stored in repository 18. Hash table 62 is organized to store 
object data using an object identifier as a key. Preferably, the database used to 
implement the hash tables of repository 18 generate the key for storing information 
m a hash table by providing an object identifier (OID) as an argument to a hashing 
function. The value generated by the hashing function is used as a key for storing 
date in a hash table. Because use of serialized data object data would not be 
efficiently hashed to generate a key, the hash table used to store object data does not 
have a corresponding mveise table. Instead, an OID is used as a key to store object 
data in hash table 62 after the object data has been serialized, that is, converted to 
string oata. An object's class name is stored in the non-inverse table 64a as the key 
tor the OID of the corresponding data object. Likewise, object methods are stored 
in non-inverse table 68a as the key for the OID of the corresponding object and the 
return types for^methods of the objects are stored in the non-inverse table 72a as 
the key for the OID of the corresponding object. The data value returned by a 
method of an object is concatenated with the object's class n ^ and method to 
generate a key that is used to store the OID in non-inverse table 74a. In the inverse 
table of each of the mirrored table pairs, the OID is used as the key to store the data 
value that is the key for the OID in the non-inverse table. 
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Hunt, column 7. lines 4?- 49 factually , Mnr* p .M) 
Object identifieis are preferably generated by capturing system time in 
milliseconds since a certain date in 1970 and concatenating that value with the 
number of objects processed by the instance of interface 20 being used by an 
application 14. Tbis object identifier (OID) is preferably generated in string form and 
is returned to application programs 14 as well as being used to store data in object 
repository 18. However, in distributed errvironments, two instances of interface 20 
may have processed the same number of data objects and may generate an object 
identifier at the same time. Accordingly, both instances would generate the same 
object identifier. As a result, the object identifier may be provided to the wrong 
instanceof interface 20 for retrieval of the object without detection or an attempt to 
store different objects in the same repository with the same OID may occur To 
reduce the Kkelihood of this occurrence, generation of the OID is performed as 
discussed above except a prefix string corresponding to the name of the server on 
which an instance of interface 20 is executing is concatenated to the OID. As 
instances of interface 20 likely execute on different servers in a distributed 
environment, this method of OID generation addresses the remote likelihood of the 
same OID being generated by different instances of interface 20. 

The above portions of Hunt do not teach or suggest constructing an identifier from a 
concatenation of various attributes for an abstract data type that is substantially urnque to the 
abstract data type. Instead, Hunt merely states that the object identifier (OID) is generated by 
capturing system rime in milliseconds since a certain date in 1970, concatenating that value with the 
number of objects processed by the instance of interface 20 being used by an application 14, and 
prefixing a string corresponding to the name of the server on which an instance of interface 20 is 
executing. 

The Office Action also asserts that Fischer teaches the comparing of signature hash values 
from the database with signature hash values from the class ck&iirion, at column 30, lines 24-44 and 
55-58, column 30, line 66 - column 31, line 12, and column 4, lines 19-49. 

However, at the cited locations, Fischer merely discloses the following: 

Fischer, column 30. lines 7 4-44 factually, lines 55-^ 
In reloading a class, it is necessary to reestablish the class exactly as it existed 
before The reload class routine begins at block 1202 where a newclassBlockis 
created which corresponds to the prospective load (block will be deleted in case of 
iaJure). the classBIock is connected to the class list and an indication is made as to 
whether the classBIock is incompletely loaded as previously described to detect 
circular inheritance. 

A check is made at block 1206 to determine whether class p-code definition 
is alreadyprovided m the celL If so, then the routine branches to block 1230 and 
processes the p-code image as carried in the cell. If the p-code definition is not 
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present, then a check is made to determine if the class source code definition is 
provided in the celL If so, then the routine branches to 1220 and processes the 
source image as carried in the celL If neither the p-code not source code is present, 
then the routine proceeds to block 1210 where the class definition is indicated by 
program name, by program version, by p-code and source hash. Hie name (and 
possibly the hash) of the class is used to locate (another) local copy of the p-code or 



Fischer, column 30. lines 55-58 frcfiallv. 

If die source code has been located, then at block 1220, it is compiled and 
the hash of the source is computed. If the computed source hash matches that 
defined in , the authenticated aspect of the cell, then the class is accepted. It is 
possible that the source hash is based not on the enact source, but rather a 
normalized form, for example, with the comments removed and nonessential 
spacing deleted. Thereafter, in block 1220, the class authorization is established 
associated with the source code. The source definition is compiled using whatever 
compiler is appropriate to the source definition if multiple languages are supported. 

Fischer, column 3Q, line 66 - colu mn 3 1. line 1? 

ki u , S? C ? si0B t d, f n co ™« ™ bIock 1232. If the prior processing involved a 
block 1230, then the located version of the p-code is loaded from the local file 
repository or within the cell itself. The hash of the p-code is computed as it is loaded. 
A check is made to ensure that the precompiled p-code is in a format eligible for 
being processed by this interpreter/executor and the class authorization is 
established that is associated with the p-code. A check is made to determine whether 
the computed hash of the p-code equals the expected value as defined in the 
authenticated pare of the celL If there is a match, then the class is accepted. If not, an 
error indicator is generated. The processing at 1232 additionally saves the hash of the 
original source which is given in p-code. 

Fischer, colu mn 4. lines 19-49 
f This provides integrity by insuring that changed "torary" or template 
versions of a class program cannot inadvertently operate on older instance data; or 
mat other incorrect versions of a class program cannot be inadvertently used (and 
cause confusion or damage) when a cell is activated at different rimes by a variety of 
users (recipients) [even if one of the users may have a class program with a matching 
name]. The unambiguous binding between instance and class maybe provided in a 
variety of ways including: 

by binding an object instance in a cell to its class by including the class 
defrmnon-Le., the class program logic itself, whether it be in source, p-code or 
marching code-as part of the cell data structure. 

By binding an object instance in a cell to its class by including in the cell a 
[cryptographic] HASH of at least one of: the SOURCE instructions (or normalized 
version thereof); the pseudo-code Op-code) instructions resulting from compilation; 
or the machine language code resulting from compilation-f or the class program 
definition. 

The binding correlates to each instance with precisely the correct 
corresponding class program-so that another class with the same name, or an 
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anackromsuc version (too old or too new) of the class-cannot be inadvertently 
sdected to operate on the easting version of instance data, when the cell is reloaded. 
This is especiaUy useful for class programs that perform critical or sensitive 
functions. In this fashion, "master" class definitions maybe changed without 
impairing or confusing existing instances that depend on the specification of the 
class definition at the tune the instance was created. 

Toe above portions of Fischer do not teach or suggest storing a signature hash value both in 
a database and a class definition for the abstract data type, so that at a later time the signature hash 
value from the database can be compared with the signature hash value from the class rfc finm™., 
afterthe class definition is instantiated, in order to verify that the class definition is not outdated. 
Instead, Fischer merely describes how the source code of a class definition is hashed, but this 
hashing function is performed each rime the source code is located and is not stored in the source 
code. 

Finally, the Office Action asserts that Morel teaches the storing of the hash value in the class 
definition, at column 8, lines 57-63 and column 5, lines 33-62. 

However, at the cited locations, Morel merely discloses the following: 

M orel, column S , lines 57-61 forma lly, column K. line 51 - column 9. lm» 7\ 
When the facility generates an object identifier (including a lineage identifier 
and a distinguished identifier) for an object, it associates that object identifier with 
the object so that (a) when a user decides to establish a link to the object, the facility 
can establish a link containing the object identifier; and (b) the facility can search for 
objects having a certain object identifier when resolving the link. In a preferred 
embocWu, when the facility associates an object identifier with an object, it stores 
the object identifier inside the object. In this way, the object knows its own object 
identifier. The facility preferably establishes an object identifier table that maps 
object identifiers to the pathnames of the associated objects. "When an object 
idennfieris generated for an object, the faciHty updates the object identifier table to 
include a mapping of that object identifier to the pathname of the object. If the user 
moves or renames the object, the facility updates the pathname stored in the object 
identifier table. Storing the object identifiers in a table permits the faciHty to ouicldy 
search for objects. 

MoreL column 5. lin« K.M 

The system links a client object to a source object by storing a link containing 
the source object's lineage identifier in the client object. A link also contains 
information for distinguishing the source object from other objects having the same 
lineage identifier. When resolving the link to the source object, the system selects the 
lineage identifier and the distinguishing information contained in the link The 
system then searches for an object with the selected lineage identifier and 
distinguishing information. When an object with the selected lineage identifier and 
distinguishing information is found, the system resolves the link to the found object 
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2E,£l i Kneage ^ distinguishing inforrnation is 

not found, the system searches for an object with the selected lineage identifier 
2^2?*"* ^ the sekcted distinguishing information. When an object with the 
ot^ ^ ldenbfieriS found « link system resolves the link to this found 

r , , V* 1 " 1 ^fsohong a link, the system preferably searches forthe source object of 

fiS, m - f 7*?? ? 311 °P dnal0 ^ svstempreferab£fct check 

a^nan^ stored in the link, then searches a hinted volume, then searches all local 

S^f" V u W ^ aUTOrnatic volume ^ then searches volumes 

ma manual volume kst, then searches volumes in remote volume lists indicated by a 
hst of remote volume lists then broadcasts a search request to all connected 

J* SyS l em P^bfy also implements an object identifier table that maps 
from objectjdeoofiers used m links directly to file system identifiers, thereby 
b^assmgd,e step of looking up a source object file name in a directory specified by 

Ine above portions of Morel do not teach or suggest storing a signature hash value both in a 
database and a class definition for the abstract data type, so that at a later time the signature hash 
value from the database can be compared with the signature hash value from the class definition, 
after the class definition is instantiated, in order to verify that the class definition is not outdated. 
Instead, Morel merely describes a lineage identifier for a source object being associated with a copy 
object to indicate that the copy object derives from the source object. 

Consequendy, even when combined, Hunt, Fischer and Morel do not teach or suggest the 
limitations of Applicants' claimed invention. Moreover, the various elements of Applicants' claimed 
invention together provide operational advantages over the references. In addition, Applicants' 
invention solves problems not recognized by the references. 

Urus, Applicants* attorney submits that independent claims 1, 6, 8, 12, 17, 19, 23, 28, 30, and 
34 are allowable over Hunt, Fischer and Morel Further, dependent claims 2-4, 9-10, 13-15, 20-21, 
24-26, 31-32 and 35-39 are submitted to be allowable over the references in the same manner, 
because they are dependent on independent claims lf 6, 8, 12, 17, 19, 23, 28. 30, and 34, respectively, 
and thus contain all the limitations of the independent claims. In addition, dependent claims 2-4, 9- 
10, 13-15, 20-21, 24-26. 3 1-32 and 35-39 recite additional novel elements not shown by the 
references. 

HI. Conclusion 

In view of the above, it is submitted that this application is now in good order for allowance 
and such allowance is respectfully solicited Should the Examiner believe minor matters still remain that 
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can be resolved in a telephone interview, the Examiner is urged to call Applicants' imdersigned 
attorney. 

Respectfully submitted, 

GATES & COOPER UP 
Attorneys for Applicants 

Howard Hughes Center 
6701 Genter Drive West, Suite 1050 
Los Angeles, California 90045 
(310) 641-8797 

Date: September^ 2004 ^ ^ 

Nam&G&fee HT Gates 
GHG/ Reg. No.: 33,500 
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